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IN THE SPECIFICATION: 

Please replace the paragraph starting at p. 7, line 4 of the specification with the 
following replacement paragraph: 



Fig. 2 is a block diagram of a computer network 200. Network 200 includes a 
source entity 202 and a destination entity 204 interconnected by a plurality of layer 3 de- 
vices 206-220. In particular, source entity 202 is connected to layer 3 device 206 by link 
222, and device 206, in turn, is connected to layer 3 devices 208 and 210 by links 224 
and 226, respectively. Device 208 is connected to layer 3 device 212 by link 228, and 
device 210 is connected to layer 3 devices 214 and 216 by links 230 and 232, respec- 
tively. Devices 212-216 are each connected to layer 3 device 218 by links 234, 236 and 
238, respectively. Device 216 is also connected to layer 3 device 220 by link 240, and 
device 220 is connected to layer 3 device 218 by link 242. Layer 3 device 218 is con- 
nected to destination entity 204 by link 244. 



Please replace the carry over paragraph between pages 7 and 8 of the specification 
with the following replacement paragraph: 



Layer 3 devices, including device 206, typically do not take into consideration the 
various processing, memory and traffic management resources at individual routers of 
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nod e s in when making ks path determinations. Thus, although two paths may have the 
same hop count, messages may experience reduced latency along one path because of 
greater processing, memory and/or traffic management resources within the nodes of that 
path and/or faster transmitting capabilities of the respective links. A service provider or 
network administrator may be interested in determining the latency experienced by mes- 
sages following different paths having the same hop count. 



Please replace the paragraph starting at p. 9, line 28 of the specification with the 
following replacement paragraph: 



A suitabl e Suitable platforms for layer 3 devices 206-220 are the 7500® series of 
routers or the Catalyst 8500® series of switch routers both from Cisco Systems, Inc. of 
San Jose, California. 



Please replace the paragraph starting at page 12, line 1 1 of the specification with 
the following replacement paragraph: 



Unlike conventional RSVP Path messages, latency determination engine 340 di- 
rects the message generator 344 to insert at least two options in an options area 418 fol- 
lowing the IP DA field 416 of the IP header 402. In particular, message generator 344 
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preferably inserts both a source routing option 420 and a router alert option 422 into the 
options area 418. The source routing option 420, which may be in accordance with either 
strict or loose source routing, includes a type field 424, a length field 426, a pointer field 
428 and a route data field 430. Within route data field 430, latency determination engine 
340 directs message generator 344 to enter in sequential order the IP addresses for the 
respective interfaces of each layer 3 device 206, 210, 214 and 218 along the selected 
path. Latency determination engine 340 may be manually provided with these IP ad- 
dresses by the service provider or network administrator, or it may discover these IP ad- 
dresses automatically. For example, latency determination engine 340 generate and send 
one or more packets to destination entity 204 carrying the well-known record route op- 
tion of the IP protocol. As described below, by including a source routing option 420 in 
path state setup message 400, the latency determination engine 340 at source entity 202 
constrains the path state setup message 400 to follow the selected path. Consequently, 
path states are only established at the layer 3 devices along the selected path. 



Please replace the paragraph starting at page 13, line 3 of the specification with 
the following replacement paragraph: 



Path message area 404 also includes a plurality of fields, which, in the preferred 
embodiment, are similar to the fields of an RSVP Path message. In particular, path mes- 
sage area 404 includes a version field 432 specifying the version of the RSVP protocol 
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being utilized, a flags field 434 containing flags which are, as of yet, undefined, a mes- 
sage type field 436, which is preferably set to "1" to indicate that message area 404 is to 
be treated like an RSVP Path message, a checksum field 438, a time to live (TTL) field 
440 that is similar to TTL field 408, and an RSVP message length field 442 that specifies 
the length of path message area 404. Path message area 404 also includes a sender tem- 
plate object 444 and a session object 446. As described in detail below, a previous hop 
field 448 will be added to the path message area 404 of message 400 by the first layer 3 
device along the selected path of network 200 (Fig. 2) (i.e., device 210). As generated by 
message generator 344, however, message area 402 does not include a previous hop field 
448. Although path message area 404 may include a sender traffic specifier (tspec) field 
450, in the preferred embodiment it is omitted. 

Please replace the carry over paragraph between pages 17-18 of the specification 
with the following replacement paragraph: 



The reservation message area 504 also includes a plurality of fields, which, in the 
preferred embodiment, are similar to the fields of an RSVP Resv message. In particular, 
reservation message area 504 includes a version field 518 specifying the version of the 
RSVP protocol being utilized, a flags field 520, containing flags which are, as of yet, un- 
defined, a message type field 522, which is preferably set to "2" to indicate that message 
area 504 is to be treated basically as an RSVP Resv message, a checksum field 524, a 
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time to live (TTL) field 526 that is similar to TTL field 508, and an RSVP message 
length field 528 that specifies the length of reservation message area 504. Reservation 
message area 504 further includes a filter specification (spec) object 530, a session object 
532, and a next hop address field 534. Although message area 504 may include a flow 
specification (spec) object 535, in the preferred embodiment it is omitted. Destination 
entity 204 loads the filter spec object 530 with information derived from the sender tem- 
plate object 444 of the path state setup message 400. In particular, destination entity 204 
loads a length field 536, a class number field 538 and a class type field 540 as provided in 
the RSVP specification for filter spec objects. In an IP SA field 542 of the filter spec 
object 530, destination entity 204 loads the IP address of source entity 202, as provided in 
IP SA field 458 of the sender template object 444. In a source port field 544, destination 
entity 204 loads the source port, if any, being utilized by the source entity 202 for this 
traffic flow, as provided in the source port field 460 of the sender template object 444. 

Please replace the paragraph starting at page 23, line 16 of the specification with 
the following replacement paragraph: 



At layer 3 device 210 the same process occurs, resulting in the message being 
forwarded to layer 3 device 214 by virtue of the path state established at device 210. 
From device 214, the test message is forwarded to device 218, which, in turn, forwards it 
to destination entity 204. The latency determination engine of destination entity 204 is 
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preferably configured to return the test message to source entity 202. That is, destination 
entity 204 generates a second test message containing the time record received from 
source entity 202. The second test message is similarly handed down to the network 
communication facility for transmission. Here, the second test message may be encap- 
sulated into a transport layer packet similar to packet 150 (Fig. IB) with message (con- 
taining the time record) loaded into data field 1 56. The transport layer packet is encap- 
sulated into one or more IP packets, similar to packet 100 (Fig. 1 A). In the source and 
destination port fields 152, 154, destination entity 204 loads the values from fields 460, 
472, respectively, of the path state setup message 400, that was used to establish the path 
states from destination entity 204 to source entity 202. Destination entity 203 204 simi- 
larly loads fields 122, 126 and 128 of the test message with the values from fields 470, 
458 and 468, respectively, of the corresponding path setup message 400. 



